Traditionally, communication of data between devices has depended on the ability for such devices to operate using a common communication protocol. Backwards compatibility is a familiar problem that confronts a communication system built on any particular protocol. As a communication system evolves over time, new features often require modifications to be made to the original protocol on which the system is built. As such, newer versions of the original protocol may be introduced from time to time for use in the system. While the latest devices may be adapted to communicate using the latest version protocol, existing devices already deployed in the field may only be adapted to communicate using an older version protocol. In fact, a given system may contain an assortment of devices adapted to communicate using various older versions of a protocol.
FIG. 1 illustrates an example of communication between two devices 102 and 104 having different data processing capabilities that can lead to backwards compatibility problems. As shown, device 102 is an older piece of equipment that is adapted to generate and process an older version of a particular communication protocol. Device 104 is a newer piece of equipment that is adopted to generate and process a newer version of the communication protocol. Newer device 104 receives data 106, which conforms to the older version of the protocol, from older device 102. If newer device 104 is built to process the older version as well as the newer version of the protocol, newer device 104 will be able to process data 106. This is possible because at the time newer device 104 is built, the older version of the protocol would already be known.
In the other direction, older device 102 receives data 108, which conforms to the new version of the protocol, from newer device 104. Here, older device 102 is unlikely to be able to process the newer version of the protocol. This is because at the time older device 102 was built, the new version of the protocol would not have been known. Specifically, older device 102 may be unable to extract any useful information from data 108, because data 108 may be in a format unrecognizable to the older device 102. Worse yet, the attempt to process this unrecognizable data may affect the ability of older device 102 to process other data or otherwise cause temporary or permanent malfunctions in older device 102. Thus, backwards compatibility problems can lead to serious, even catastrophic breakdowns, if not properly addressed.
The need to preserve particular structures within a protocol, in order to retain functions and to control bandwidth overhead, further complicates the task of resolving backwards compatibility issues. For example, FIG. 2 is a bit format diagram of the general structure of a message 200 in an Integrated Services Digital Network (ISDN) protocol for digital transmission of data. This diagram illustrates certain aspects of an ISDN protocol pertinent to the present discussion and does not attempt to capture all of the details of the protocol. Message 200 may be a D-channel message containing control and signaling information that facilitate the transfer of data between at least two devices. Generally speaking, message 200 is a unit of data having a variable length and an internal structure that includes other units of data. Other messages in the protocol may have fixed lengths and/or different internal structures.
As shown, message 200 is organized as a series of bytes, or octets, of data. Message 200 includes a message type 202 in the first octet and two information elements 204 and 206 in the following octets. Message type 200 identifies message 200 as a specific message. For example, a particular binary value of “00000010” for message type 202 may indicate that message 200 is a SETUP message, in accordance with an assignment of message type values such as shown in the following table:
Message TypesBits87654321Definition00000001STATUS00000010SETUP00000011CONNECT00000100DISCONNECT00000101SUSPENDetc.
As a SETUP message, message 200 would pertain to the establishment, or “setup,” of a communications link. In this example, information elements 204 and 206 would be two pieces of information relevant to the SETUP message. While only two information elements 204 and 206 are illustrated, a greater number of information elements may exist in message 200.
FIG. 3 is a bit format diagram of one of the information elements 204 and 206 contained in message 200. Information element 204 will be discussed here for purposes of illustration. Generally speaking, information element 204 is a unit of data having a variable length and an internal structure that includes other units of data. Other information elements in the protocol may have fixed lengths and/or different internal structures.
As shown, information element 204 includes an information element identifier 302, an information element length field 304, a type of number field 306, a numbering plan identification 308, and number digits 310. Information element identifier 302 identifies information element 204 as a particular information element. Consistent with the example of message 200 being a SETUP message, a particular binary value of “00000100” for information element identifier 302 may indicate that information element 204 is a CALLED NUMBER information element, in accordance with an assignment of information element identifier values such as shown in the following table:
Information Element IdentifiersBits87654321Definition00000001CONGESTION LEVEL00000010PROGRESS INDICATOR00000011CALLING NUMBER00000100CALLED NUMBER00000101PACKET SIZEetc.
As a CALLED NUMBER information element, information element 204 would contain information relevant to the called number, that is, the number of the party being called. Specifically, type of number field 306 is used to specify the classification of the called number as a local number, a national number, an international number, or some other type of number. Numbering plan identification 308 is used to specify the number plan of the called number as an ISDN/telephony numbering plan, Teletex numbering plan, national standard numbering plan, private numbering plan, or some other numbering plan. Number digits 310 specifies the n digits of the called number itself. Finally, information element length field 304 specifies the length of the contents of information element 204. Here, such contents would include type of number field 306, numbering plan identification 308, and number digits 310.
The structure shown in FIGS. 2 and 3 illustrate a particular ISDN protocol used for communicating data. This structure accommodates many different functions important to the implementation of a communication system. However, when such a system evolves over time and requires new functions to be created, the structure shown in FIGS. 2 and 3, in many respects, make it difficult to make desired modifications to the protocol. For instance, FIG. 3 shows that information element 204, as a CALLED NUMBER information element, has a fixed format that contains type of number 306, numbering plan identification 308, and number digits 310. As the system employing this protocol evolves, a new data field may become necessary, and the fixed format of FIG. 3 would need to be changed to accommodate the new data field. This has the potential of causing backwards compatibility problems. That is, existing device in the field adapted to processing the fixed format of FIG. 3 would be asked to handle a CALLED NUMBER information element having a structure different from that shown FIG. 3.
One alternative would be to create a new information element to handle the new data field. However, this approach has many disadvantages. First, it may be undesirable to organize the new data field in an information element other than the CALLED NUMBER information element 204. For example, it may be more efficient to process only the CALLED NUMBER information element 204 in order to access all data fields relevant to a called number (including the new data field), as opposed to processing both the CALLED NUMBER information element 204 and the new information element in order to access the same set of data fields.
Second, as shown in FIG. 3, the protocol discussed above uses a single octet (8 bits) to represent information element identifier 302. Accordingly, information element identifier 302 can take on a maximum of 2^8, or 256 possible values. As discussed above, this protocol has already assigned some of these 256 possible values to particular meanings. Once all 256 possible values have been assigned, there is no more room for identifying new information elements. It may be the case that no new information element can be created, because all possible values of information element identifier 302 have been assigned. Furthermore, it may not be feasible to expand information element identifier 302 to a size greater than one octet. Such an approach could significantly increase the bandwidth overhead of the protocol by inflating the size of a frequently transmitted data field. Similar problems would plague an approach that uses new message types to accommodate new data fields.
Protocols other than the ISDN protocol discussed above suffer similar problems. These include protocols operating on the same layer of data communication as the ISDN protocol, as well as those operating on other layers of data communication. Thus, existing communication protocols in general fail to provide a suitable arrangement that facilitates protocol modifications and properly resolves the associated problems of backwards compatibility.